-
Notifications
You must be signed in to change notification settings - Fork 245
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generic Toom-3 multiplication for gr_poly #2071
Conversation
Interesting! |
doc/source/gr_poly.rst
Outdated
int gr_poly_mul_toom33(gr_poly_t res, const gr_poly_t poly1, const gr_poly_t poly2, gr_ctx_t ctx); | ||
|
||
Balanced Toom-3 multiplication with interpolation in five points, | ||
using the Bodrato evaluation scheme. Assumes commutativity and division by 3. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is meant by "division by 3"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We require that the ring supports exact division by 3, i.e. (3x)/3 = x; in other words the characteristic should be 0 or not divisible by 3.
Actually, division by 2 is required too; I should update this comment.
Are there any requirements on the length, i.e. minimal length, for any of the functions? |
No, but this algorithm is most efficient when the operands are approximately balanced. For unbalanced products one should use an unbalanced Toom rule instead. |
For fun, this is the theoretical speedup of Karatsuba vs classical and Toom-3 vs Karatsuba for an n x n multiply, counting arithmetic operations (in Toom, multiplication or division by 2 or 3 counts as an arithmetic operation here): This is when using the brute forced optimal cutoffs classical -> Karatsuba -> Toom-3 for the recursive multiplications (in particular, Karatsuba and Toom-3 are not used at all when suboptimal). Of course, counting all arithmetic operations as having unit cost isn't realistic; this just gives a rough idea. The curves aren't quite smooth because Karatsuba performs a bit better when n is even, and Toom performs a bit better when n is divisible by 3. Raw number of arithmetic operations:
|
Should be a bit better asymptotically than Karatsuba, for rings where we don't have FFT.
This can be tidied up a bit (avoiding zero-padding, etc). Not optimized for squaring, nor for unbalanced products.
Would be interesting to see how Bodrato's sequence (used here) compares to a completely generic Toom-(n,m).